Amazon CloudWatch Metric Streams で New Relic にメトリックデータを流し込んでみる（Step-by-Step）

先月末に発表された CloudWatch Metric Streams、もうみなさんは試されたでしょうか！

• CloudWatch Metric Streams — AWS メトリクスをパートナーと自身のアプリにリアルタイムで送信 | Amazon Web Services ブログ
• Using metric streams - Amazon CloudWatch

上述した弊社ブログ記事 でご紹介したようにこの機能はメリットが満載なので、使える環境にいるかたは是非試してみることを御検討ください。
特に初期パートナーの各 SaaS を使われている場合は置き換えるメリットは大きいです。ただ設定入れ替え作業中は監視が一時中断するため、慎重になるのは当然かと思います。

この記事では実際に、 New Relic にデータを流し込むための CloudWatch Metric Streams を設定してみます。
やることは下記のステップになります。

1. New Relic にて AWS インテグレーションの設定を追加開始する
2. インストラクションに従い AWS 上で IAM ロールを作成する
3. 作成した IAM ロールの ARN を New Relic に登録
4. AWS 側の Metric Streams 設定・リソースを CFn テンプレートから作成
5. Enjoy!

ちなみにこちらの手順は、New Relic から公開されているブログ記事・ドキュメントにそったものになります。
詳細が確認したい場合はこちら（とくに ドキュメント）もあわせてご参照下さい。

• New Relic One and Amazon CloudWatch Metric Streams - New Relic Blog
• Amazon CloudWatch Metric Streams integration | New Relic Documentation

やってみる

では順にやってみましょう。以下スクショ多めでちょっと長いですがお付き合い下さい。
作業完了後は下記の様な構成になります。

なお、Metric Streams の設定は AWS のリージョンごとにする必要があるので、手順 4. で CFn を流すリージョンは気をつけてください。
基本的には監視したいリソース（EC2 など）が存在する AWS リージョンが対象になると思いますが、CloudFront や Route 53 などのグローバルサービスのメトリックを送信したい場合はバージニア北部リージョン（us-east-1）に Metric Streams を作成する必要があります。

この辺り、どのAWSリージョンに設定するかは、見たいメトリクスが CloudWatch のどのリージョンのダッシュボードに出力されているかを確認して決めて下さい。

ちなみに複数の AWS リージョンから Metric Streams を流す場合でも、New Relic 側の AWS インテグレーションはひとつでいいです。手順内で作成している IAM ロールやライセンスキーなども共通でも大丈夫なので、AWS で CFn を流す（Kinesis Data Firehose と Metric Streams を作成する）部分だけ必要なだけ繰り返して下さい。

0. 事前準備

まずは以下の情報を調べたり（作ったり）決めておいたりしましょう。

• 調べるもの
  • New Relicライセンスキー
  • New Relic アカウントのリージョン（US or EU）
• 決めること
  • 作成するS3 バケット名（送信失敗したストリームデータの保存用）

上記以外のものはインストラクション内で表示されたり例示された通りで良かったり、デフォルト値があったりします。

New Relic ライセンスキー

New Relic の日本語記事にもありますが、右上のメニュー（プロフィールアイコン）より API Keys を開いた画面から管理画面に入れます。

すでに出来合いのものが有ると思うのでそれでもいいのですが、ここはひとつ今回のために作成してみましょう。「Create key」をクリックすると作成画面にはいります。

• Account : AWS インテグレーションを追加したいアカウント（New Relic のアカウント名）になっていることを確認します
• Key type : ドキュメント上なぜかどこにも明記されてませんが、用途的にIngest - Licenseを選択して下さい
• Name: ライセンスキーに名前を付けます。Metric Streams 用と分かりやすい名前がいいでしょう
• Notes: 名前とあわせて簡単なコメントを記載します。作った目的と、日付なんかをメモしておくのも良いですね

出来上がったキーはコピーしてどこかにメモしておくか、後で使うためにブラウザのタブかウィンドウを残しておいて下さい。キー右横の「…」アイコンから Copy できます。

ちなみに「ライセンスキー」という名前ですが、使われ方はほとんど API キーなので取り扱いにはご注意を。
ライセンスキーについての詳細は下記をご参照下さい。

• New Relic ライセンスキー | New Relic Documentation

New Relic アカウントのリージョン

普段あまり意識しないかもしれませんが、New Relic は北米（US）と欧州（EU）の二ヶ所にデータセンタがあります。
そのどちらを使われているかで New Relic 側の HTTP エンドポイント FQDN が変わるため、ここで確認しておいて下さい。

調べ方は、下記記事の下の方に書いてあります。

• New Relic のEUデータセンターのご紹介 - New Relic公式ブログ
• Verify your account is based in EU region - Our EU and US region data centers | New Relic Documentation

具体的には下記が確認ポイントです：

• APM などの UI の URL に、rpm.eu.newrelic.comなどとeuがついている
• ライセンスキーがEUで始まる

作成する S3 バケット名

Kinesis Data Firehose には、正常に New Relic に送信できなかったストリームデータを S3 バケットに保存（バックアップ）する機能があります。

• Choose New Relic for Your Destination - Choose destination - Amazon Kinesis Data Firehose

用意されている CFn テンプレートはこの S3 バケットもいっしょに作成するので、その名称をここで指定します。
既に存在する S3 バケット名を指定すると CFn スタックの作成に失敗するので、いまは存在しないものを決めておいて下さい。

ちなみにここは地味に重要で、つまり複数リージョンに Metric Streams の設定を追加しようと思ったら、リージョンごとに S3 バケットを用意する必要があるということです。
EC2 は東京、でも CloudFront も使ってる、など複数リージョンを New Relic で一元モニターしたい需要は普通にあると思うので、最初から考慮しておきたいですね。

S3 バケットを増やしたくないという気持ちもあるんですが、使い勝手的にもここは分けて置いた方がいいでしょう。ここではやってませんが、予めバケット名にリージョン名を足しておくのも手だと思います¹。

さて、準備ができたら作成にはいりましょう。

1. AWS インテグレーションの設定

New Relic にログインした状態で、Infrastructure > AWS とクリックします。
既存の AWS インテグレーションの設定があり追加する場合には右側の「+ Add an AWS account」を、まだ設定がない場合は「Set up Amazon Web Services integrations.」をクリックします。

↑既存がある場合

↑ない場合

どちらの場合も同じ画面にくると思います。

ここで「Use metric streams」をクリックします。

2. インストラクションに従い AWS 上で IAM ロールを作成する

Step 1

「Create Role」のインストラクションが表示されたら、それに従って AWS 側で IAM ロールを作成します。監視対象側の AWS アカウントと New Relic アカウントの間で信頼関係を結ぶためのものです。

この IAM ロールですが、以前まで AWS インテグレーションを使っていたことがあって既に作ったことがあるなら、そちらを再利用できるため、この後Step 5 まで手順を飛ばすことができます。
とはいえロール ARN は必要になるため、念のため IAM ロールの内容確認しつつ手順を追っても良いし、あえて作り直してもいいです。その場合は IAM ロール名名を微調整（後ろに「2」とつけるとか）したりしてください。

それではやってみましょう。ブラウザの別ウィンドウ or 別タブにて AWS マネジメントコンソールにログインし、IAM -> ロール -> ロールの作成をクリックします。

• 「別の AWS アカウント」をクリック
• アカウント ID : 754728514883 (New Relic 側の AWS アカウント ID)
• オプション : 「外部 ID が必要」にのみチェック
• 外部 ID(External ID) : New Relic のインストラクション Step 1-4. に表示されている ID ² をコピペ
• 「MFA が必要」にはチェックしない

全て入力したら「次のステップ: アクセス権限」をクリックします。
併せて New Relic 側のインストラクションも一番下の「Next」をクリックしましょう。³

Step 2

New Relic 側の画面は引き続きインストラクションですね。

これに従って AWS 側を操作します。

「Attach アクセス権限ポリシー ⁴」のフィルタに「ReadOnlyAccess」と入力してしぼりこみ、リストのほぼ一番下近くにある「ReadOnlyAccess」を見つけてチェックを入れて下さい。

次の画面に移るのですが、New Relic 側のインストラクションでは「Next: Review」となってます。AWS 側の UI は「次のステップ: タグ」となっていて整合性がとれていないですが、構わず AWS 側は「次のステップ: タグ」をクリックして下さい。

そしてタグの入力画面になりますが、タグはオプショナルなので取りあえず無視してもいいです。必要であれば付けて下さい。

そして「次のステップ: 確認」をクリックして下さい。
併せて New Relic 側のインストラクションも一番下の「Next」をクリックしましょう。

Step 3

これまでと同じように、インストラクションに従ってフォームを埋めます。

• ロール名 : NewRelicInfrastructure-Integrations
• ロールの説明 : 任意。空欄で可

ロール名は New Relic からこの名前を強く推奨されてますが、要は分からなくならないようにということで。

信頼されたエンティティに「754728514883」、ポリシーに「ReadOnlyAccess」と、想定通りの値が表示されていることを確認して「ロールの作成」をクリックします。

「ロール NewRelicInfrastructure-Integrations が作成されました」と表示されてますね！
このロールの ARN をコピーしなくてはならないので（New Relic インストラクションの 3.）、この NewRelicInfrastructure-Integrations をクリックします。下のロール一覧画面から検索してクリックしてもいいです。

ロール ARN の行の右端にコピーアイコンがあるので、それをクリックしてコピーします。あとで使いますので、メモ帳なりにどこかにペーストしておいてください。ARN は下記の様な文字列になります。

• arn:aws:iam::<AWSアカウントID>:role/NewRelicInfrastructure-Integrations

AWS マネジメントコンソールの画面はこのまま使いますので、閉じないようにしてください。 New Relic 側のインストラクションは「Next」をクリックしましょう。

Step 4

Step 4 です。

インストラクションに従い、作成した IAM ロールNewRelicInfrastructure-Integrationsに権限config:BatchGetResourceConfigを追加します。
先の画面の右側「インラインポリシーの追加」をクリックして下さい。

「ポリシーの作成」画面で「JSON」タブをクリックして下さい。
そして表示されるフォーム内に、インストラクションに記載されていた JSON をまるごとコピペしてください。フォームにもとから入力されていた文言はすべて上書きして大丈夫です。

「ポリシーの確認」をクリックすると確認画面になります。「名前」は何でもいいのですが、インストラクションの例に従って「NewRelicConfig」としておきましょう。

問題なければ「ポリシーの作成」をクリックして下さい。
New Relic 側のインストラクションも「Next」をクリックします。Step 5 に進みます。

3. AWS インテグレーション作成の操作を完了させる

Step 5

New Relic 側の設定に戻ってきました。
「AWS Account name」とあるところには適切な名前を入力しておきます。ここでは「Classmethod test env watanabe.seigo」としました。

続いての「Paste the ARN created in the previous step」のところには、Step 3 でコピーしたロール ARN を入力して下さい。

良ければ「Next」をクリックします。Step 6 に進みます。

4. 指示に従って CFn スタックからリソースを作成する

Step 6

ようやく New Relic 側の準備が出来ました。インストラクションは最後の画面ですが、実はこの時点で AWS インテグレーション内に Stream の設定が出来てます。興味ある方は別タブなどで開いてみて下さい。

インストラクションに戻って、この後 AWS 側にて、Kinesis Data Firehose と CloudWatch Metric Streams を作ります。

ここでは CFn テンプレートで一気につくってしまうつもりですが、もしマニュアルで作成したいと言う場合は、インストラクションにもリンクがあるこちらのドキュメントをご参照下さい。

• Amazon CloudWatch Metric Streams integration | New Relic Documentation

ちなみに CFn テンプレートを事前に確認したい、という方も当然いらっしゃると思うので、CFn テンプレートの URL に直リンを貼っておきます。

• MetricStreams_CloudFormation.yml

インストラクション Step 5 内の「Use CloudFormation」のリンクをクリック（URL をコピーして、AWS アカウントにログイン済みのブラウザ/タブで開く）すると、CloudFormation のスタック作成画面が表示されるかと思います。

ここに必要な値を入力していきます。

• スタックの名前: デフォルトで構いません（任意で変更可能）
• CloudWatchMetricStreamName: CloudWatch の Metric Streams の画面で表示される名称です。デフォルトでも構いませんが、複数作る予定があるなら AWS のリージョン名など入れて置くのもいいでしょう
• FirehoseStreamName: Kinesis Data Firehose の画面で表示される名称です。以下同文
• NewRelicDatacenter: New Relic を US/EU どちらのデータセンタで使っているかをプルダウンメニューから選択します
• NewRelicLicenseKey: New Relic のライセンスキーをコピペします
• S3BackupBucketName: 送信失敗したストリームデータの保存用 S3 バケットの名称

以下の 2 項目は AWS Config 用の設定なので、とりあえずはデフォルトのまま（false、空欄）で ok です。⁵

• CreateConfigService
• S3ConfigBucketName

ここまで問題なければ、一番下の「AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認します。」にチェックをいれて「スタックの作成」をクリックして下さい。
数分で下記リソースが作成されます。

論理 ID	リソースタイプ
CloudWatchMetricStream	AWS::CloudWatch::MetricStream
FirehoseStreamToNewRelic	AWS::KinesisFirehose::DeliveryStream
MetricStreamRole	AWS::IAM::Role
FirehoseRole	AWS::IAM::Role
S3FirehoseEventsBucket	AWS::S3::Bucket

ここまで問題なく完了したら、CloudWatch メトリクスが New Relic に流れ込んでいることと思います！

その確認は次章で行いますが、とりあえず New Relic のインストラクションは「Done」をクリックして大丈夫です。

確認

それでは、早速確認してみましょう。

AWS

AWS 側から確認する場合は、マネジメントコンソールの CloudWatch > メトリクス > ストリームを表示します。

詳細を見ると、転送したメトリクスの量も確認出来ますね。

また当然ながら、Kinesis Data Firehose の画面でも確認出来ます。

ちゃんと Destination が New Relic になってますね！　分かりやすい！

詳細画面に入ると Detail で各種パラメータが参照出来たり、Monitoring で転送量が見られたりします。
ここで、CFn から作成された Kinesis Data Firehose のパラメータなどを確認しておくのは良いかと思います。例えばRetry durationは 60 秒、Buffer conditionsは 1MiB or 60 秒となってますね。
これらのパラメータが意味するところは下記のドキュメントを参照下さい。

• Retry duration ... Choose New Relic for Your Destination - Choose destination - Amazon Kinesis Data Firehose
• Buffer conditions ... Configure settings - Amazon Kinesis Data Firehose

New Relic

New Relic 側ですが、インストラクション画面を閉じた直後、あるいは Infrastructure > AWS とクリックすると、下記の画面が表示されているかと思います。
この画面で既に、「4 つの名前空間の 29 メトリクスが特定 AWS アカウントから送信されておりエラーゼロ」なことが分かります。

もっと詳細を確認する方法はいろいろありますが、ひとまず Account status dashboard をクリックしてみて下さい。

少し気になるところを見ていきましょう。

Total Metrics by AWS Region

当然ですがいまは東京リージョンだけのメトリクスが送信されてきています。複数リージョンに追加した場合はここにそれらのリージョンが並ぶことが予想されますね。

Total API calls

Metrics Streams にしたら API コールが無くなると思ったんですが、実はいろいろなメタデータを収集するために API コールしていましたｗ　まあ IAM ロールを作っているし AWS Config 設定もあるのでここは想定の範囲内なのですが。同時に CloudWatch API はコールされていないのも確認出来ますね。
本記事の検証期間内でコールされていた API は以下のものでした。

• AWSResourceGroupsTaggingAPI
• AmazonConfig
• AWSSecurityTokenService

3 番目は API アクセスのための AssumeRole API だと思うので無視すると、主にセキュリティグループのタグ情報を集めてる感じですね。

そのレートはトータルで、今回設定した環境だと概ね 20 分間隔で 800〜1,000 前後。AWS 側のリソース数や、今後 New Relic 側のバージョンアップなどで変化する可能性はありますが、監査・セキュリティ目的などで API コールを監視している場合は念頭に置いておいて下さい。
API コールの詳細は AWS 側の CloudTrail で調査確認が可能です。ユーザー名にnewrelic-infrastructureと指定するなどしてみてください。

Permission errors

発生しているエラーが一覧表示されます。今回以下の 2 種類のエラーが各 3 リージョンごとに発生していました。

• Fetch tags for all integrations
• Fetch Metadata for AWS integrations

ですが発生しているリージョンは全て「オプトインで有効にしないと使えないリージョン（ケープタウン、香港、ミラノ）」でしたので、今回は気にする必要はなさそうです。

Total Metrics by AWS Namespace

CloudWatch メトリクスの名前空間、つまり「どんなメトリックが送信されてきているか」が表示されます。
ここ（ステータスダッシュボード）では名前空間ごとのメトリクス数しか参照出来ませんが、具体的にどんなデータが届いているかは、これまでの AWS インテグレーションと同様に Explorer や NRQL などで検索してみて下さい。

例えば、直近 30 分以内に Metric Streams 経由で流れ込んだメトリクスを全て表示する場合は、下記の様な NRQL になります。

SELECT *
FROM Metric
WHERE collector.name = 'cloudwatch-metric-streams'
SINCE 30 minutes ago

なお、先の Status dashboard の表示を見て貰えばわかるとおり、現状だと特定リージョン内の全ての CloudWatch メトリクスが New Relic に送信されています。

個人的な意見としては「ぜんぶ New Relic で見てええやん」という気はするのですが、ケースによって不要なメトリックは送信しないほうがコスト的にもありがたいハズです。

というわけで、次の章でフィルタしてみます。

送信するメトリクスを名前空間でフィルタする

CloudWatch メトリクスの名前空間 (Namespace) 単位で、送信する・しないをフィルタできます。操作は AWS マネジメントコンソールで、New Relic 側で選択ではないのでご注意下さい。
まず CloudWatch メトリクス > ストリームと進み、メトリクスストリームの詳細を表示して、右上の「編集」をクリックして下さい。

開くとすぐに「ストリーミングするメトリクス」という欄があると思うので、「選択された名前空間」を選び、送信する名前空間をプルダウンメニューから選択します。
ここでは試験的に EC2 と EBS のみにしてみました。

最下段の「変更の保存」をクリックすると保存されます。
メトリクスストリームの詳細画面に「選択された名前空間」という項目が出来ているのがわかりますね。

しばらく時間をおいてメトリクスの送信量を見てみると、確かに変更したタイミングから減っているのが確認出来ました。

試しに New Relic 側でも見てみると、ちゃんと EC2 と EBS 以外のメトリックが来なくなってますね。

まとめ

CloudWatch Metric Streams で New Relic にメトリクスをストリーム送信する設定をやってみました。けっこう複雑な手順に見えたかもしれませんが、インストラクションが丁寧なのでそう悩むこともないかと思います。
それに 1 度やればそうそうやり直すことでもないので、New Relic で AWS インフラを監視している方はぜひやってみて下さい！

脚注